6.05. Бизнес-логика
Бизнес-логика
Как менеджер, так и аналитик, работают с таким понятием, как требование – представление потребности, пригодное для использования. Оно сосредоточено на понимании того, какая ценность может быть получена в результате выполнения требования. Кто-то называет это спецификацией – словом, это то, что должно быть реализовано в процессе. В нашем случае – в процессе разработки. Требования могут быть конкретизированными, общими, или какими-то специфичными, вроде требований к функционалу, приёмке. Это некое описание, которое отражает потребность.
В английском языке есть понятие design (дизайн), которое как может подразумевать «оформление», так и проектирование. По нашему пониманию проще воспринимать отдельно дизайн как оформление, а касательно проектирования – проект. Дизайн и требования – похожие вещи, но дизайн это вроде конкретного варианта реализации решения, тогда как требование – просто может быть общим изложением.
Требования могут изложить просто в сообщении в мессенджере, вроде «хочу сайт, который будет генерировать мне случайные фильмы для просмотра на вечер». А могут быть в виде огромного технического задания с подробным описанием всех полей, структур, с примерами дизайна сайта, а также перечнем сопутствующих вопросов, которые нужно будет решить.
Выделяют три уровня требований:
- бизнес-требования;
- требования пользователей;
- требования к решению.
Бизнес-требования же отличаются тем, что они формулируют цели, задачи, результаты разработки, без углубления в технические моменты. Как раз AS IS, TO BE. Туда можно включать бизнес-цели, концепцию решения, какие-то рамки и границы, критерии готовности, описания пользователей. Словом, общий контекст.
Бизнес-требования могут в себе содержать бизнес-правила, определяющие или ограничивающие конкретные моменты. Пример бизнес-правила – заявитель должен быть совершеннолетним. В таком случае, бизнес-требования будут содержать это правило, а команде разработки придётся реализовать техническими средствами проверку на соответствие этим условиям (валидация). Бизнес-правило является условием поведения системы или её конкретных элементов.
Требования пользователей, или пользовательские требования – описание с точки зрения выполнения сценария, через два варианта:
- User Story – пользовательская история, которая приводит пример, играя роль соответствующего пользователя, при этом короткая, простая и акцентируется на потребностях пользователя, без деталей - «Как [роль], я хочу [действие], чтобы [цель/выгода]. »;
- Use Case – более детальный сценарий, указывающий уже «как» должна вести себя система, указав роль, цель, шаги и альтернативные потоки, к примеру, «покупатель жмёт кнопку, система выводит окно с подтверждением, если да – выполняет, если нет – возвращается на шаг назад».
Требования к решению, или спецификация включает в себя:
- функциональные требования (описание поведения системы по данной функции – самые детальные особенности именно тут);
- нефункциональные требования:
- требования к данным – объектная модель, связи, атрибуты, свойства;
- требования к интерфейсу (пользовательский интерфейс, внешний вид);
- ограничения (какие-то особые условия, допустим набор технологий);
- системные требования (требования к программному обеспечению и оборудованию, на котором будет функционировать разработанное решение);
- показатели качества (удобство использования, производительность, доступность, безопасность).
Все требования, как правило, документируют по завершению анализа, потом проверяют на соответствие бизнес-цели и верифицируют.